This invention relates generally to a computer system and specifically to a computer system that includes software for converting dates at the turn of the century.
With the upcoming turn of the century, much has been discussed about how computers will react when the date turns from 1999 to 2000. The problem stems from the fact that many computers store the date in a two-digit format. In other words, the year 1998 would be stored simply as xe2x80x9c98xe2x80x9d. The computer can then determine the year by adding 1900 to the stored year (e.g., 1900+98=1998). Of course this system will fail at the year 2000 since the only digits stored would be xe2x80x9c00xe2x80x9d and 1900+00=1900.
One particular instance where this problem exists is in a personal computer (PC) using the IBM AT or PS/2 standard. These systems utilize a real time clock (RTC) such as the Motorola MC146818 RTC which stores the date with three bytes (six nibbles) in packed BCD (binary coded decimal) format. The last two nibbles are used for the year. The MC146818 RTC also includes a non-volatile memory. By convention, two nibbles of this memory are reserved for the century. Since the RTC only stores the data and cannot manipulate this byte, the system must maintain the correct century.
One method for maintaining this date is suggested by the National Software Testing Laboratories in a white paper entitled xe2x80x9cYear 2000 Compliance and the Industry Standard Personal Computer.xe2x80x9d This paper suggests an algorithm whereby any two-digit year less than 80 (since Microsoft DOS does not recognize any years before 1980) be interpreted as a corresponding date between 2000 and 2079. An algorithm is provided in the paper and repeated here.
Read date
If (year less than 80) {
If (century less than 20) {
century=20
Read date
}
}
Return date
This algorithm will check if the year is less than 80. If so, the algorithm assures the date is between 2000 and 2079 and corrects it if it is not.
The present invention is provided to solve a number of deficiencies in the prior art. In one aspect, the present invention is a driver designed to fix the 1999-2000 century change problem. Unlike other Year 2000 (Y2K) fixes, this solution is proactive. The current date and time from the RTC is monitored at regular intervals and the 1999-2000 year change is made in the last one or two seconds of 1999.
In one embodiment, the present invention is a software driver stored within a memory in a computer system such as a personal computer or PC. The driver will monitor the current date and time at periodic intervals. At the periodic intervals, the driver will determine whether the date stored in the non-volatile memory is equal to a predetermined date. If it is, the driver will determine whether the time stored in the non-volatile memory is a predetermined amount of time before the end of the predetermined date. If both these date and time conditions are met, the non-volatile memory will be updated with the day after the predetermined date at the beginning of the day.
In one particular embodiment, the driver will recognize a timer interrupt (e.g., Interrupt 08) and, in response, determine whether the date is equal to Dec. 31, 1999. If it is, the driver will determine whether the time is a predetermined amount of time before the end of the day (e.g., equal to 23:59:58 or 23:59:59). If these date and time criteria are both met, the date and time will be set to Jan. 1, 2000 and setting the time to 00:00:00.
Unlike the prior art solution suggested by the National Software Testing Laboratories, this algorithm prevents 1900 from ever appearing as the RTC year. Fixes like that described in the Background react to the RTC clock year of 1900 and suffer from the latency between century roll-over and the software recognition. The RTC year is invalid during the latency period. In other words, immediately following the turn of the century, there will be some time in which the RTC believes the year is 1900. While this latency may be minimized, it cannot be not eliminated by looking for a xe2x80x9c00xe2x80x9d in the date field. Latency must be completely eliminated to fully support direct RTC port access.
With the present invention, the date will be correct regardless of how the clock is accessed. As is known, there are two ways that software can obtain the date from the RTC: via BIOS (e.g., Interrupt 1Ah) or by reading the RTC directly (e.g., via I/O ports 70h and 71h). Prior art solutions such as the one proposed by NSTL will only work with the former. The present invention, on the other hand, will update the clock before it is ever accessed by software. This way, the clock will be correct regardless of the manner in which it is accessed.